Ham Radio 2000 #2

home *** CD-ROM | disk | FTP | other *** search

/ Ham Radio 2000 #2 / Ham Radio 2000 - Volume 2.iso / HAMV2 / TCP_IP / TNOS230B / NEW2TN2.00 < prev next >

Wrap

Text File | 1996-08-17 | 22.9 KB | 492 lines

Upgrading TNOS to release 2.00 http://www.lantz.com/Update2.00.html TNOS 2.00 will be the next release of TNOS, to be released sometime before the formation of the United Federation of Planets. Hopefully, this list of changes will give you an idea of the scope of work that has occurred between versions. Of course, it may be faster just to re-read the docs when the next version is released. This document is divided into: * Bug Fixes * Improvements * Minor Changes * Known Bugs * To-Do List ------------------------------------------------------------ Bug Fixed: The following bugs have been squashed. * Cosmetic bug in 'mbox status' display fixed. * Export buglet fixed If you went to use the 'export' function, it worked fine, but BIDs didn't get placed on personal messages. * Fixed an ax25 heard bug Wouldn't log heard activity correctly if NETROM compiled in and the netrom interface not initialized. * Minor errors when compiling without Domain Server Some misplaced conditionals moved. * Convers long user listing would occasionally loop - fixed * Changes to only add a SMTP 'Sender:' line if none already exists Also, no longer will it wrongly add a Sender line also to the mini-RFC lines in the message data. * Fix for RXECHO and multi-drop KISS Thanks to Tomi Manninen <tpmannin@snakemail.hut.fi>, the RXECHO now works correctly with multi-drop kiss (on 'kiss' type interfaces) * Non-blocking buglet in Convers, fixed * Fixed occasional lingering 'AX25 listener' sockets ------------------------------------------------------------ Improvements: The following optimizations and improvements have occurred. * System statistics added Added connection statistic logging, inspired by the FBB Connections Server. There are three displays, a general display like this: CONNECTS: BBS SERVERS Connects since Jun 17: 39 23 Connects since midnight: 39 23 Average time per connect: 13 min, 36 sec 20 min, 42 sec Average connects per day: 39 23 Rush hours: At 18 and 17 o'clock At 17 and 18 o'clock a daily display of usage by hour, like this: Usage per hour in the last 24 hours (excluding current hour) BBS SERVERS * * ** * ** * * ** * * ** ** * ** *** ** ** **** ***** **** * ***** * **** ******* ******* ------------------------ ------------------------ 0 0 0 0 0 1 1 1 1 1 2 2 Hour 0 0 0 0 0 1 1 1 1 1 2 2 Hour 0 2 4 6 8 0 2 4 6 8 0 2 0 2 4 6 8 0 2 4 6 8 0 2 and a weekly display of usage by day, like this: Usage per day in the last 7 days (excluding current day) BBS SERVERS *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** --------------------------------- --------------------------------- SUN MON TUE WED THU FRI SAT SUN MON TUE WED THU FRI SAT These have been added as a separate Command Session 'stats' command, and a BBS 'stats' command, each with 'general', 'daily', and 'weekly' subcommands. There are also three new pre-defined users in fingerd, which give these displays, named 'general', 'daily', and 'weekly'. The BBS connects include users, BBS forwarding sessions (incoming and outgoing), and RLOGIN sessions to remotely sysop. The SERVERS connections are the Conference Bridge (users and links), FTP sessions, TTYLINK sessions, ECHO sessions, DISCARD sessions, Information Server sessions (INFO, TUTOR, and NEWS), SMTP sessions, TCPGATE sessions, and TRACE Server sessions. Things not included in the statistics, of course, are services where the connection is NOT made to you, but THROUGH you, such as digipeating, IP forwarding, smart routing, etc. * Changes made to PBBS export functionality In 1.14, all forwarding sessions defined as connecting via 'export', would all go into a 'current.exp' file. So though you COULD define multiple BBSs to be exported (or change one temporarily, if needed), they would be output together. Now each BBS defined as an 'export'-type forwarding session stores their messages in a file named 'xxxx.exp', where 'xxxx' is the BBS name defined in forward.bbs. If you want to set up for a generic export file, simply define a BBS in forward.bbs named 'export'. The previous actions of 1.14, using 'current.exp' are still there, they just now use 'export.exp', for a BBS named 'export'. * Changes made to support exporting a BBS's messages There will be occasional times of difficulty, where you might need to bundle up a sysop's messages and give them by a non-usual method, due to electical storms, etc. So I changed the 'forward kickone' command to not only take a 'poll' command, but also an 'export' command. If the 'export' parameter is given, then the connection method will be 'export', no matter what is set in the forward.bbs file. * Also added a 'stats monthly' command Added to the command session and BBS. Also a new finger user of 'monthly'. The output of this looks like this: Usage per day in the last month (excluding current day) BBS SERVERS * * * * * * * * * * ** ** ** ** ** ** ** ** ** ** -------------------------------- -------------------------------- 0 0 0 0 0 1 1 1 1 1 2 2 2 2 2 3 Days 0 0 0 0 0 1 1 1 1 1 2 2 2 2 2 3 Days 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 * Added code to automatically bounce 'refused' SMTP mail While the BBS code will properly refuse mail that rewrites to 'refuse', the SMTP server was accepting it, and placing it in the 'refuse' area. Now the SMTP server will reject the message, causing it to bounce back to the original sender. * Changed the new 'stats' command Placed the 'general', 'daily', 'weekly', and 'monthly' commands under a 'stats connection' subcommand. * Added a new 'stats' subcommand level - 'messages' While the output is nearly identical and the subcommands are the same as the 'connection' subcommand, the 'messages' statistics report number of incoming and outgoing messages, whether it be by SMTP, BBS user entry, or PBBS forwarding. * Added nos_remote.c to the source tree This is a native Unix program, that serves as a xNOS-like 'remote' server, to allow remote rebooting. You may not need it, but it's there if you do. * Added in Jack's FBB non-compressed code and changes These required a *little* bit of changes, but very few. Jack did an *EXCELLENT* job, not only of coding it, but also integrating it into the 'TNOS world'. He only missed two minor points, and *that's* GREAT! On the initial day of testing, it was put into a real-world test, receiving over 750 bulletins over the air with a FBB system. No problems! * Added a signal handler (for Unix) for the TERM signal This handler simply calls the where_outta_here() function, so that all needed cleanup can occur, primarily the writing of statistics files and exit log entry. * Changed the 'stats connect' subcommand to 'stats usage' Better description of the data as a whole. * Added a 'yearly' command to the 'stats usage' and 'stats message' commands Display is very similar to the monthly histogram. * Added a 'stats traffic' command This reports number of bulletins, personal messages, NTS messages, and total number of messages forwarded via PBBS forwarding. Good data for use in reporting traffic to ARRL leadership. Has the same histogram displays as the 'usage' and 'message' stats subcommands, except that since there is four pieces of info for this command, there are two histograms for each display. Might need to have your session set for '--more---' paging. * Added APOP support to the POP3 client and server From Paul Traina <pst@w6yx.stanford.edu> (thanks, Paul). Added POP "APOP" authentication support for both pop3 client and server. APOP is an extension supported by MH, Eudora, and many other POP clients to avoid sending passwords over the air in the clear. This extension works by adding a challenge string "<random-data@host>" to the pop login banner. If that string is detected by an APOP capable client, we concatenate our password onto that challenge, take the MD5 digest, and send back "APOP username digest" * Added a 'stats forwarding' command This reports number of incoming and outgoing PBBS forwarded messages, listed by BBS name. This *only* covers the total number of messages forwarded via PBBS forwarding, and does *not* cover any messages that have been forwarded (incoming or outgoing) using SMTP. Good data to have in tracking traffic flows. Has the same histogram displays as the 'usage', 'message' and 'traffic' stats subcommands, with one difference. Since the data is per BBS, there is an additional parameter for the subcommands, that of the BBS you wish info on. * Added LZW command and code to POP3 Client and Server This came in from the current JNOS code, so there should be no incompatibilities between the two. * Resolved inconsistencies between JNOS and TNOS with LZW FTP The problems were caused by the way that my LZW/FTP support was placed into JNOS. They made the LZW (for no real reason) turn off and on between files. This was invisible to the user, but caused the TNOS server to respond with errors when receiving the 'XLZW' command again. If a TNOS client connects to your TNOS server, it will act as before. If a JNOS client connects to your TNOS server, it will now co-operate. * Added a 'stats area' command This reports number of messages listed, read and received by area, and the number of times someone changes to that area. Good data to have to determine whether or not certain topics of messages are of interest to your userbase. Has the same histogram displays as the 'usage', 'message', 'traffic' and 'forwarding' stats subcommands, with one difference. Since the data is per area, there is an additional parameter for the subcommands, that of the area you wish info on. Like the 'traffic' stats, there are 2 sets of histograms for each report. Might need to have your session set for '--more---' paging. * Resolved differences between TNOS and JNOS on LZW support for FTP Good news and bad news. The *GOOD* news is that JNOS and TNOS can now FTP using LZW without any problems. Also gained, is that the FTPclient 'LZW' command (which used to just be an 'on' switch), now toggles between using and not using LZW. The *BAD* news is that 1.15 TNOS will *not* behave (in regards to LZW FTP) with pre-1.15 TNOSs! The change in coding is subtle, but won't work together. NOTE: LZW transfers will only occur for ASCII FTP data transfers, so if using binary/image mode, only directories will be compress (which are ALWAYS in ASCII mode). So LZW and ASCII mode are a team. In the fight between LZW and binary mode, binary mode always wins. ;-) I have resisted doing this mod, since TNOS *originated* FTP LZW, and the JNOS port of the code was what *broke* the interrelating of the two. Don't expect future TNOS workarounds for JNOS bugs......... * Remote sysop commands added From Jack/KF5MG: changes to allow remote sysops to do telnet, ping, finger, etc. using the mbox gateway versions of those functions. i.e. you can telnet to port 513... do some SYSOP type things and then ping ucsd.edu to see what's going on. * Added in Jack's FBB *compression* code These required a *no* changes, but I made changes, anyway ;-) All cosmetic relating to the fbb trace output. This adds a 'forward fbb-compression' command. * Completed the FBB spec, with support for the negotiation checksum This code checks/calculates/rejects the checksum on negotiations, completing the FBB spec. The incoming negotiations are checksummed, and *IF* the checksum is transmitted after the "F>", then it is compared, and if it fails, it drops the connection. All outgoing negotiations send the checksum. * Changes to the forward.bbs syntax, allowing digis on connect line This creates an AUTO route to the BBS, using the digis given, as a BBS gateway command does. And, just as the BBS gateway command does, this *will* override/eliminate any existing 'LOCAL' (manually entered) route. The AUTO/LOCAL route problem *is* on the TODO list.... * Support for setting the time of TNC PMS clocks, added * COMPLETE change of the syntax for the forward.bbs file A new program, cnvfwd, will convert the old format forward.bbs file to the new... * Added code to allow restricting message sizes for forwarding Using the new forward.bbs file, you can set up maximum message sizes for different times or connection paths. * Added code to provide Alternate BBSs For details and syntax, see the TNOS Forward.bbs File Specification. * Added code to provide for multiple paths to a BBS; automatic retries For details and syntax, see the TNOS Forward.bbs File Specification. * Added code to the FBBFWDing to properly handle area address rewriting Now honors a configured rewrite address (per area) in the forward.bbs file. * Added "tcp clean" command This one is from Selcuk Ozturk <seost2+@pitt.edu> extensions to JNOS. It resets all FINWAIT2 state connections. He was seeing a lot of them lingering forever. You can use this command in conjunction with "at" as: at now+0300 "tcp clean+" to periodically reset hanging connections. * Added a 'CLOCKOFFSET' Attribute to the forward.bbs file syntax This allows you to account for setting clock of remote TNCs in different time zones. * Added a 'FBBSIZE' Attribute to the forward.bbs file syntax This allows you to set a maximum size for the proposed data sent. Normally, with the default for 'FBBSIZE' of zero, there will be up to 5 messages sent during the negotiation (assuming you have at least 5 to send). If 'FBBSIZE' is set, then after added a message to the negotiation, a check is made to see if the total size of the negotiation is now larger than the 'FBBSIZE', and if so, no more messages will be added to the negotiation block. This means that the maximum size of your block could be ( 'FBBSIZE' + 'SIZE' - 2) This is *IF* there was at least one byte less than the 'FBBSIZE', and the next message was one byte less than the 'SIZE'. For example, if the 'SIZE' Attribute is 6K, and the 'FBBSIZE' Attribute is 6K, and message 1 is 2K, message 2 is 2K, and message 3 is 5K, then it will not attempt to add a 4th message. You will see that the negotiation size is 9K. * Added to the forward.bbs syntax ability to nest conditionals * Added a 'ELIF' conditional processing directive to forward.bbs syntax * Added code to help prevent troublesome messages from clogging forwarding If a forwarding connection (while sending a message or messages) aborts due to an error, loss of connect, or the other side having a problem with what we were sending, the message(s) are left in a blocked state, with the status byte within the *.fwd file (first byte of line) set to '!'. On later forwarding sessions, these block message(s) are skipped (but not removed), allowing the other messages to pass. When a forwarding session to that BBS sucessfully completes, these blocked message(s) are un-blocked, and the next forwarding time will be attempted again. ------------------------------------------------------------ Minor Changes: The following minor changes have occurred. * Extended syntax of Command Session 'sleep' command I had some cases where I wanted to script in delays of less than 1 second, so I extended the syntax to 'sleep xxx [m]', where 'xxx' is the number of seconds, OR if the 'm' is present, 'xxx' is the number of milliseconds. * Made outgoing forwarding sessions honor maintenance mode No outgoing forwarding sessions will start during maintenance mode. Any forwarding sessions active when maintenance mode occurs, will quietly terminate at the end of the current message, even if 'mbox maintclear' is off. * Changes to make DOS DGROUP limitations less frequent Changed several DGROUP-hog files, to make there dynamically assigned string constants into global DFAR char arrays. Won't do away with DGROUP errors, but will make then happen less frequently. * Changed order of priority in BBS listing flags Previously, if a held message was deleted, then listed, it showed as held. Now the same message is shown as deleted, which IS more important. * BBS check for newmail ALSO between time a line entered and processed The check for newmail (current area or personal area) used to be done after execution of a command. That means, if you KNEW a message had come in while you were at the command prompt, and did a command to use that message (like 'list'), you would NOT get the message accounted for with that command, but THEN it would check. This required doing the command a second time. Now, in addition to checking for new mail AFTER a command is executed, it is also checked between receiving the command, and executing it. * Added to the 'forward summary' the queue data sizes per BBS Each message size is now stored in the forwarding queue files (*.fwd) for quick access of this info. A total data size queued for forwarding is also given. * Added a 'forward tapr [on|off]' to allow (if you MUST) a non X.3.4 haddress While only TWO TNOS users have 'complained' about the TAPR addressing issue being forced, I will allow you to by-pass this, but it *WILL* lecture you about it if you disable it ;-) ------------------------------------------------------------ Known Bugs: The following are known bugs that are being worked on during the development of release 1.14. These may or may not be fixed in release 1.14. * TCPGATE won't compile in DOS version Missing some references in the source. Will be fixed soon... ------------------------------------------------------------ To-Do List: The following are things on my 'to-do' list that may eventually be done, but not necessarily by the next release. * Linux kernel AX25 devices available from TNOS/Linux This would allow the PI card to be used.... * Add capability to allow use of OS commands This WILL be limited to Linux version. * FTP permissions improved The new UNIX-like dir display needs a little more work with the permissions portion of the display... * Add in UNIX permissions checking to FTP server This could cause problems with restricted files not being restricted. * Add a command to allow a sysop to edit the header of a message This will be handled by making each editable line at least a certain minimum length. Care to be taken to PREVENT editing older messages, by checking the line length of these header lines BEFORE starting the edit. * Add better support for PBBS<->Internet mail address translation The 'translate' file and improved handling of aliases is a START, but more work needs to be done here. Maybe a 'translate.out' file... * Put in special case code to better handle message number rollover This is a far less frequent problem in TNOS, with the separate message sequence and temp sequence numbers, but the problem will STILL occur when the message sequence number wraps around past 65535 for MIDs (or 99999998 for temp sequence numbers). A special flag to indicate that the message scan detected a rollover should be added, and special case code added to alter the last message read and number of messages based on whether a rollover is in that area. * Better handling of AUTO/LOCAL ax25 routes Current code takes any 'AUTO' route given to it (by a BBS gateway, a Command Session 'connect/split' command, or a forwarding connect command) and *if* there was a LOCAL (manually entered) route, that route disappears, and is replaced by the AUTO one. This AUTO route disappears when that connection is severed, leaving (now) *NO* route. This is obviously caused by only allowing *one* route to a destination per interface. The fix would be to allow 0/1 LOCAL routes, and 0/1 AUTO routes, with an AUTO route being used for current connection, and disappearing when the connection is *made*, rather than completed. This prevents the problems created when someone is *guessing* at how to connect to a sight (making an invalid AUTO route), while someone who wishes to let the system determine the route suffers. * Support for GCC/ELF binaries of TNOS The setjmp/longjmp routines seem to have been changed, and POSSIBLY have a buglet in them. The initial setting up of a process is fine, and you can enter into any process fine, but when exiting (and doing a setjmp), the data is NOT left as expected. The first process to be entered for the *second* time, causes a segment fault. * Support (optimization) for ncurses 1.9.x for performance * Color support output to Linux console The various color commands don't work with the Linux kernel and curses. Annoying, but just possible unexpected output. No crashes.